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(57) Abstract: The encapsulation of MPEG (Motion Pictures Experts 
Group) within a label switching protocol such as MPl^ (Multiple Pro- 
toco] Label Switching) is used to implement a multimedia communi- 
cations network. The network advantageously improves the delivery 
of customized services to network subscribers. Encapsulating MPEG 
within MPLS simplifies network deployment by converging the pre- 
viously distinct environments of data communications and broadcast 
television service over cable TV networks. In addition, the encapsula- 
tion of MPEG within MPLS allows merging MPEG program content 
streams with IP streams at the MPLS multiplexing level. This allows 
for applications such as meiging MPEG video programs with IP ad- 
vertising. Furthermore, the MPEG Digital Storage Medium Command 
and Control (DSM-CC) protocol may be used for label distribution for 
the label switching network. 
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MPEG IN A LABEL SWITCHING ENVIRONMENT 

FIELD OF THE INVENTION 

The present invention relates generally to the arts of communication networks and 
multimedia, and more particularly, to a multimedia program delivery system (and 
associated methodology) for delivering information flows to network subscribers or users. 

BACKGROUND OF THE INVENTION 

Current digital multimedia networks can generally be divided into a few main 
categories. One category of digital multimedia networks is a data network based upon the 
Internet Protocol (IP). IP networks were primarily designed to carry unicast information 
between two hosts. Though IP has the capability for multicast, IP routers and switches 
have not been very efficient at forwarding broadcast or multicast infonnation. In fact, the 
IP network layer is designed to control traffic and prevent many broadcasts from 
transversing the routers of a network. When IP was developed, the bandwidth of 
switching devices and routers far exceeded the bandwidth of transport and transmission 
technologies. Thus, the IP network layer was designed to make routing decisions to keep 
information from being broadcast across the slow modem and X.2S links of the original 
Internet. With the development of fiber optics and the introduction of technologies such 
as Wave Division Multiplexing (WDM), transport bandwidth has grown at a faster rate 
than the silicon bandwidth of switching technologies such as routers. As a result it may 
now be more efficient to allow larger percentages of data to pass through the transport 
network without the normal access restrictions implemented through network protocols 
such as IP. 

Another category of networks that could be used for delivering digital multimedia 
to subscribers is a network that creates a connection to each destination. This could be 
done with point-to-point links, circuit-switched coimections, or virtual-circuit, packet- 
switched connections. Often these connection-oriented technologies allow for network 
resource allocation to implement quality of service (QoS) for real-time information flows 
such as multimedia audio or video programs. However, these connection-oriented 
technologies become unreasonable as the number of subscribers needing connections 
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increases. Thus, these connection-oriented technologies do not scale very well. 
Furthermore, there have been many difficulties encountered in using connection-oriented 
ATM transport networks to deliver connectionless IP datagrams. 

Another form of digital multimedia delivery network is the CATV (Community 
Antenna Television) network or cable TV network where content is generally broadcast 
or narrowcast to a large number of subscribers on a distribution network. Historically, the 
CATV network has included many frequency-division multiplexed chaimels that are 
distributed to a large number of subscribers. In the past, the CATV network has had a 
large amount of bandwidth to deliver information or data to many subscribers, but the 
CATV network's capabilities were limited for delivering customized programming for 
specific subscribers. This made it difBcuh to deliver subscriber-controllable and 
network-controllable features through existing CATV networks. 

Switching and multiplexing technologies are well known in the art, but a brief 
description is included in the following paragraphs for clarity. Those skilled in the art 
will be aware that spatial separation, time separation, and frequency separation are three 
common ways of separating electromagnetic signals to allow multiple electromagnetic 
signals to be communicated. The concept of a communication media or medium can be 
thought of as a signal path that is spatially separated from the interference or noise of 
other interfering signals enough to allow the communication of information with the 
signal. This signal path may be a physical link or a wireless link. Within a 
communications medium time-division multiplexing and/or frequency-division 
multiplexing are often used to allow the communications medium to carry multiple 
information flows. Furthermore, the various multiplexing methods can be used within 
other multiplexing methods. For example, time-division multiplexing can be used inside 
of frequency-division multiplexing. This is a non-limiting example as there are many 
ways of combining multiplexing methods and creating multiplexing hierarchies of the 
same type of multiplexing method. 

Digital signals may be communicated on a communications medium using various 
methods. One simple method is to use a square wave to communicate the signals. 
Networks using such square waves are often referred to as baseband or unmodulated (/.e., 
non-frequency-shifted) transmission systems. These networks may allow multiple signals 
to share a communications medium through time-division multiplexing. This is in 
contrast to modulated signals that are frequency shifted outside of the base bandwidth 
(Le., the baseband) of a square wave representation of the data. Modulation may also be 
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used to share a communications medium with muhiple signals, each signal being placed 
within its own frequency band. This technique is known as frequency-division 
multiplexing. In some of the original IEEE (Institute for Electrical and Electronic 
Engineers) LAN (Local Area Network) standards, the terms baseband and broadband 
were used to indicate unmodulated, baseband transmission and modulated transmission, 
respectively. For instance for Ethernet, lOBaseT means 10 MBPS (mega-bits per 
second), baseband, twisted-pair while 10Broad36 described a frequency-shifting, 10 
MBPS, broadband system. The term broadband also has been used to describe 
communication systems with relatively higher capacity bandwidth as opposed to systems 
with relatively lower capacity bandwidth that are often known as narrowband systems. 

The two primary types of time-division multiplexing are 1) static or fixed TDM 
and 2) dynamic or statistical TDM. Static or fixed TDM is used in circuit-switching 
technologies such as the PSTN (Public Switched Telephone Network) as built in the 
1 960s to 1 990s. In static or fixed TDM, once the capacity of a time channel is allocated 
for a circuit-switched connection, the bandwidth is used up regardless of the actual 
transmission of information over the time channel. Dynamic or statistical TDM is used in 
packet-switching to more efficiently allocate bandwidth based on an as-needed or on- 
demand basis. Common packet-switching technologies include Ethernet switching, 
Internet Protocol (IP) routing, X.25, frame relay, and ATM (Asynchronous Transfer 
Mode). 

Packet-switching technologies can be categorized into two types: 1) 
connectionless or datagram packet-switching and 2) connection-oriented or virtual-circuit 
packet-switching. In connectionless or datagram packet-switching, no connections or 
paths are established prior to the source being able to communicate with the destination. 
Instead, the packet switch or router forwards each packet based on a path or route 
determined at the time that the packet switch or router receives the packet. In datagram 
packet-switching networks, each packet transmitted from the source to the destination 
may follow a different path through the network. Due to different delays from following 
different paths, the packets in a datagram packet-switching network may arrive at the 
destination in a completely different order than they were transmitted by the source. IP is 
a common example of a connectionless, datagram packet-switched protocol. 

In contrast, in connection-oriented or virtual-circuit packet-switching a connection 
or virtual circuit is setup between the source and destination that want to communicate. 
The connection allocates resources in the network between the source and destination. 
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and the connection establishes the network path to be used by packets communicated 
from the source to the destination. In virtual-circuit packet-switching the packets 
transmitted from the source to the destination all generally follow the originally allocated 
path and arrive at the destination in the same order as they were transmitted by the source. 
Common examples of packet-switching technologies that use connection-oriented, 
virtual-circuits are X.25, frame relay, and ATM. There are two main types of virtual 
circuits: 1) permanent vurtual circuits (PVCs), which are usually configured by network 
administrators because they are infrequently altered and 2) switched virtual circuits 
(SVCs), which are often setup on demand by network users and applications. SVCs are 
generally more complicated because they require protocols to allow network users and 
applications to signal the network for establishing, managing, and releasing the SVCs. 

Due to the historical limitations inherited from many of the earlier networking 
technologies, it has often been difficult, inefficient, and costly to deploy networks capable 
of broadcasting and multicasting digital multimedia information to subscribers as well as 
providing data connectivity to these subscribers. These historical networks usually 
encapsulated digital multimedia packets such as those formatted to the MPEG (Motion 
Pictures Experts Group) standards into packets conforming to network level protocols 
such as the Internet Protocol (IP). For IP, these network level packets are known as IP 
datagrams. Furthermore, advances in label switching technology, as found in such 
protocols as MPLS (Multi-Protocol Label Switching), have often focused on 
encapsulating network level packets such as IP datagrams into label switched frames. 
MPLS was primarily designed to carry network protocols with a special emphasis on the 
Internet Protocol (IP) due to the ubiquitous nature of IP based networks. Also, the 
common method of delivering MPEG packets is to encapsulate them inside IP datagrams. 
However, a simple straight-forward combination of label switching technologies to 
encapsulate network level packets such as IP datagrams that then encapsulate MPEG 
packets leads to inefficiencies and makes it more difficult to deliver broadcast and 
multicast services to subscribers. This problem in providing digital services that are 
similar to the services provided by CATV broadcast networks is at least partially due to 
the addressing limitations of the IP protocol. 

Though IP is a robust protocol that offers many advantages, it was designed at a 
time when network technologies were significantly different than they are today. Due to 
the large deployment of IP capable equipment and the large number of networks carrying 
IP traffic, many network improvements focus on the IP protocol without ever 
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reconsidering some of the initial design decisions made in the IP protocol. When IP was 
designed, the bandwidth of wide-area links between computers was severely limited. As 
a result IP routers generally limit traffic on wide-area links by filtering packets based on 
IP addresses. With the increased bandwidth of fiber optic cable, these assumptions of the 
Internet protocol (IP) may no longer be valid. Furthermore, the filtering rules of IP 
routers may actually be limiting the simplified deployment of some services such as 
broadcast and multicast digital multimedia. Thus, this disclosure suggests solutions to 
these networking problems and reconsiders the necessity for carrying MPEG packets 
within IP datagrams inside of MPLS fi:ames. 

SUMMARY OF THE INVENTION 

The preferred embodiments of the present invention provide a method (and 
associated devices) of using MPEG packets encapsulated in a label switched protocol 
such as MPLS (Multiple Protocol Label Switching) to overcome limitations of previous 
networks. An embodiment of the present invention includes implementing label 
switching fimctionality, implementing MPEG fiinctionality, and encapsulating MPEG 
packets within label switching fiinctionality. Normally, MPEG would not be considered a 
network protocol, which is what label switching protocols are generally designed to 
encapsulate. However, the use of the preferred embodiments of the present invention in a 
network advantageously improves the delivery of customized services to network 
subscribers. Encapsulating MPEG within MPLS simplifies network deployment by 
converging the previously distinct environments of data conununications and broadcast 
television service over cable TV networks. In addition, the encapsulation of MPEG 
within MPLS allows merging MPEG program content streams with IP streams at the 
MPLS multiplexing level. This allows for applications such as merging MPEG video 
programs with IP advertising, as one non-limiting example. Furthermore, for those label 
switching devices that are MPEG-aware, the MPEG Digital Storage Medium Command 
and Control (DSM-CC) protocol may be used for label distribution for the label switching 
network. Other common protocols may be used to distribute labels to non-MPEG-aware 
label switching equipment. Thus, all the label switching equipment in the network does 
not have to be MPEG-aware. 

The preferred embodiments of the present invention advantageously simplify the 
delivery of multimedia information flows to network subscribers and promote the 
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convergence of previously distinct historical perspectives on network technologies. 
These historical perspectives primarily developed from the data networks for computers 
that predominately use unicast and multicast packets and from the CATV networks for 
video and other multimedia content delivery that generally use broadcast and narrowcast. 
The preferred embodiments of the present invention resolve some of the previous 
problems with the delivery of digital multimedia services to subscribers as well as allow 
simplified deployment of new services such as personal television. 

The preferred embodiments of the present invention advantageously use MPEG 
packets in a label switching environment to allow the convergence of many of the 
previously described network technologies. The preferred embodiments of the present 
invention overcome many of the limitations of the previously described network 
technologies to deliver multimedia content to subscribers. In an embodiment of the 
present invention, the network is designed based on the understanding that the restrictions 
of an IP network layer are not well suited to the deployment of a multimedia network 
where much of the traffic is broadcast or multicast to many subscribers. Furthermore, the 
increased transport bandwidth of fiber optic cables has made an IP network layer less of a 
necessity. Also, the preferred embodiments of the present invention allow for service 
flow or information flow resource allocation in the network to provide for quality of 
service (QoS) in multimedia delivery without all the complexity of end-to-end, 
connection-oriented technologies such as ATM. In addition, the preferred embodiments 
of the present invention more easily allow the multiplexing of subscriber-customized 
information within the network than was previously possible in other existing CATV 
networks. This subscriber-customized information could be used to implement new 
services. 

As stated above, although the preferred embodiments of the present invention are 
oriented to time-division multiplexing techniques, they may be used within one or more 
frequency channels on a frequency-division multiplexed medium such as current CATV 
networks. Alternatively, the preferred embodiments of the present invention could be 
used on networks without frequency-division multiplexing. Though the current cable TV 
network has a broadband structure that uses frequency-division multiplexing for 
broadcast channels, the preferred embodiments of the present invention could be used to 
carry these broadcast channels in addition to subscriber-customized information in a time- 
division multiplexed format. Thus, the preferred embodiments of the present invention 
may allow a migration away from the broadband, frequency-division multiplexed 
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architecture of current cable TV networks towards a newer baseband, time-division 
multiplexed architecture for cable TV networks. This migration may occur in stages, as 
the preferred embodiments of the present invention will likely first be used to provide 
additional and new services in a time-division-multiplexed format These example uses 
of the preferred embodiments of the present invention are not intended to be limiting, and 
those skilled in the art will be aware of unlimited variations for combining the preferred 
embodiments of the present invention with variotis time-division and frequency-division 
multiplexing techniques. This disclosure is generally not meant to imply any limitations 
as to combining the preferred embodiments of the present invention, which is generally 
related to time-division multiplexing and baseband communications, with other 
multiplexing or transmission techniques. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention can be better understood with reference to the following drawings. 
The components in the drawings are not necessarily to scale, emphasis instead being 
placed upon clearly illustrating the principles of the present invention. Moreover, in the 
drawings, like reference numerals designate corresponding parts throughout the several 
views. The reference numbers in the drawings have at least three digits with the two 
rightmost digits being reference numbers within a figure. The digits to the left of those 
two digits are the number of the figure in which the item identified by the reference 
number first appears. For example, an item with reference number 21 1 first appears in 
FIG. 2. 

FIG. 1 is a diagram of the Open Systems Interconnection (OSI) protocol model; 
FIG. 2 is a diagram showing a first location where label switching information 
may be placed in the OSI model; 

FIG. 3 is a diagram showing a second location where label switching information 

may be placed in the OSI model; 

FIG. 4 is a diagram showing label switching information between some example 
data link protocols and network protocols; 

FIG. 5 is a first diagram showing a protocol layer example with the PPP protocol 
used in a virtual private networking tunnel; 
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FIG, 6 is a second diagram showing a protocol layer example with the PPP 
protocol used in a virtual private networking tunnel; 

FIG. 7 is a diagram showing MPEG transport inside an IP datagram in a label 
switched frame where the label is included in a shim label header; 

FIG. 8 is a diagram showing MPEG transport inside an IP datagram in a label 
switched frame where the label is included in the layer 2 address fields; 

FIG. 9 is a diagram showing MPEG transport inside an ATM cell or a firame relay 
packet as used on the PVCs and SVCs of ATM and frame relay; 

FIG. 10 is a diagram showing MPEG transport directly inside a label switched 
frame where the label is included in a shim label header; 

FIG. 1 1 is a diagram showing MPEG transport directly inside a label switched 
frame where the label is included in the layer 2 address fields; 

FIG. 1 2 is a diagram showing the functions of a standard, layer 3 router; 

FIG. 13 is a diagram showing the functions of a label switching router (LSR); 

FIG. 14 is a diagram showing the functions of the MPEG Systems Specification; 

FIG. 1 S is a diagram showing how MPEG elementary streams are encapsulated in 
Packetized Elementary Streams (PES) and further encapsulated in MPEG transport 
packets; 

FIG. 16 is a diagram showing an example of how MPEG transport uses Packet 
IDs (PIDs) to multiplex many programs including many Packetized Elementary Streams 
(PES); and 

FIG. 17 is a diagram showing the use of Label Switching Routers (LSRs) in a 
label switching network for delivering MPEG to subscriber devices. 

DETAILED DESCRIPTION 

Protocol Layering 

Protocol layering allows designers to develop software and hardware without 
worrying about the details of the implementation of other parts of communication 
systems. For example, the TCP/IP protocol suite used in the Internet comprises many 
layers. The TCP/IP protocol suite is named after the Transport Control Protocol (TCP) 
and the Internet Protocol (IP), which are two of the many protocols in the protocol suite. 
FIG. 1 is a block diagram illustrating the seven-layer OSI (Open Systems 
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Interconnection) reference architecture or protocol model for communication systems. 
The seven layers of the OSI reference architecture are: 1) the physical layer 101, 2) the 
data link layer 102, 3) the network layer 103, 4) the transport layer 104, S) the session 
layer 105, 6) the presentation layer 106, and 7) the application layer 107. The OSI model 
was developed for an OSI protocol that was not widely accepted by the communications 
industry. However, the seven-layer OSI protocol model is a useful abstraction for 
evaluating and discussing conununication protocols and has become well known in the art 
for such purposes. Thus, a brief description of the model will be helpful before 
describing various embodiments of the present invention. Because the OSI model is well 
known in the art, a detailed discussion of all the features and functionality of each level in 
the OSI model will not be covered, thus, the following descriptions of each layer are 
necessarily just a high-level overview of the some the functions generally found in 
various levels of protocol stacks or suites. 

As shown in FIG. 1 , the first layer of the OSI protocol model is the physical layer 
101, which is usually concerned with the conmiunication of raw bits over a transmission 
channel. This usually involves the electrical or optical signal levels used to represent 
zeros and ones on the communications medium. Also, the physical layer 101 includes 
repeaters that regenerate and propagate digital signals. The next level of the OSI model is 
the data link layer 1 02, which generally operates to ensure that bits are delivered on the 
medium without error. The IEEE (Institute for Electrical and Electronic Engineers) 
divided the data link layer 102 into two further sublayers, the media access control 
(MAC) sublayer 102a and the logical Imk control (LLC) sublayer 102b. 

The MAC sublayer 1 02a comprises functions for grouping the bits of information 
into frames. The frames usually contain headers and trailers (or tails) as well as some 
form of error checking such as error detection or error correction codes. In addition, 
MAC frame headers often contain layer 2 addresses or MAC addresses. Layer 2 
addresses are usually included in MAC frame headers when multiple streams of 
information are multiplexed onto a communication channel and the identification of the 
various streams for demultiplexing will be based on information in the stream. For 
instance, in many LAN technologies multiple transmitting and multiple receiving devices 
can use MAC addresses to uniquely identify which devices transmitted frames and which 
devices are to receive frames on a communications medium that is shared by the multiple 
devices. 
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In fact, the Media Access Control 102a sublayer often contains rules for 
specifying which device of multiple devices can transmit or receive at a specific time 
and/or frequency on the shared medium. A commimications medium shared by a number 
of devices contending for access is often called a contention medium, a broadcast 
medium, or a multi-point medium. It is often called a broadcast medium because even 
though only one device can transmit on the medium at a specific time and firequency, 
many devices could potentially receive a broadcast frame on the medium at a specific 
time and frequency. Algorithms for arbitrating or controlling access to a shared medium 
can be distributed among the devices sharing the medium as is the case in Ethernet or the 
IEEE 802.3 CSMA/CD (Carrier Sense-Multiple Access with Collision Detection) 
algorithm. Alternatively a controller can execute a centralized algorithm to allocate 
transmission rights to resolve contention in broadcast or shared media. 

In contrast to multi-point, contention, shared, or broadcast media, there are no 
problems with conflicts over the use of the media in point-to-point media. A point-to- 
point medium is a medium connected between only two devices. In a uni-directional 
point-to-point link, a transmitter in a first device communicates in a forward direction 
with a receiver in a second device. In a bi-directional point-to-point link, a transmitter in 
a first device communicates in a forward direction with a receiver in a second device, and 
a transmitter in the second device communicates in a reverse direction with a receiver in 
the first device. 

The LLC sublayer 102b of FIG. 1 provides support for a selection between a 
datagram service, a connection-oriented service, and an acknowledged datagram service. 
The common IEEE protocol for LLC sublayer 102b is 802.2. 

Referring now to network layer 103 of FIG. I, the network layer 103 generally 
provides transparent transfer of data firom the transport layer 104. The network layer 103 
handles many of the details of the underlying data transmission, switching, and routing 
functions. To handle these functions, the network layer 103 often contains addressing 
infomiation that determines how data is switched or routed through the network. As 
mentioned above, the abstractions of the OSI model do not exactly match every working 
protocol including the TCP/IP protocol suite. Still, the IP protocol is generally 
considered to be a level 3, network layer protocol 103. 

A primary function of the transport layer 104 is to accept data from the session 
layer 1 OS and break the data into smaller pieces before passing it to the network layer 
103. In addition, the transport layer 104 often verifies that the data arrives properly at the 
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destination. From the TCP/IP protocol suite, the Transport Control Protocol (TCP) and 
» 

the User Datagram Protocol (UDP) are often thought of as layer 4 or transport layer 
protocols 104. TCP is a connection-oriented protocol that ensures in order delivery of the 
data that the TCP layer presents to higher level protocols. UDP is a connectionless, 
datagram protocol that does not guarantee delivery of information, but UDP is useful for 
many simple communications that do not need the overhead of TCP. 

The next layer of the OSI model is the session layer 105, which among other 
things provides two-way simultaneous, two-way alternating, or one-way transfer between 
two devices. The presentation layer 106 handles data translation, foraiatting, and syntax 
selection. Finally, the application layer 107 contains many commonly used functions for 
distributed applications. Examples of application layer protocols from the TCP/IP 
protocol suite include Telnet, the File Transfer Protocol (FTP), and the Hypertext 
Transfer Protocol (HTTP) that is used for retrieving web pages. 

Label Switching 

Many factors have influenced the development of label switching technology and 
standards. First, a need existed for performance improvements in IP routing to obtain the 
price-performance characteristics of switches is one of the factors. In addition, problems 
encountered in integrating IP with virtual-circuit technologies such as ATM have driven 
the demand of simplified solutions through label switching. Finally, the need to make 
more sophisticated routing decisions than the destination-based routing available in IP 
also has contributed to the demand for label switching. Originally, many vendors 
developed proprietary label switching technologies under various names including IP 
switching and Tag switching. In order to standardize some of these protocols, the Internet 
Engineering Task Force (IETF) established a working group that has developed Internet 
RFCs (Request for Comments) and draft RFCs with regard to Multi-Protocol Label 
Switching (MPLS). The preferred embodiments of the present invention are designed to 
work with any label switching technology that is capable of carrying many protocols, and 
this includes the MPLS standard as defined by the IETF. 

MPLS is a label switching protocol that was designed to work over multiple 
protocols and to carry multiple protocols within MPLS label switched frames. Generally, 
MPLS was designed to work over an OSI layer 2, data link protocol and to carry an OSI 
layer 3, network layer protocol. Though MPLS is designed for multiple protocols, the 
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main proposed use for MPLS by those skilled in the art is to carry IP datagrams (i.e., an 

» 

IP network layer). In the embodiments of the present invention, MPLS or other label 
switching technology may be used to carry MPEG transport packets. MPEG transport is 
not normally considered to be a network layer protocol by those skilled in the art. 

In general, label switching works by assigning relatively short, fixed-length labels 
to packets. The network equipment used to implement label switching is called a Label 
Switching Router (LSR). All packets that are to be forwarded in an equivalent method by 
an LSR are said to be part of a Forwarding Equivalence Class (FEC). One example of an 
FEC includes a set of packets destined for the same destination address prefix. Another 
example may be a flow of packets with a common quality of service (QoS) between two 
end-points. Packets forwarded in an equivalent manner by an LSR are assigned the same 
label and placed in the same output queue of an LSR for transmission through one of the 
LSR's output ports. LSRs generally perform the following simplified forwarding 
algorithm for label switched packets or firames: read the label on incoming packets, 
determine the FEC by looking up the incoming label in a forwarding table, swap or 
replace the incoming label in the packet with an outgoing label as determined by the FEC, 
and place the packet with the outgoing label into an output queue and/or interface for 
transmission as determined by the FEC. In some cases instead of swapping a label, an 
LSR may add or push a new label onto a label stack, or an LSR may delete or pop a label 
fi'om a label stack. The use of a label stack allows a label switched firame or packet to 
carry one or more labels. This capability of using label stacks allows more flexibility for 
label switching than the use of just a single label. For example, without limitation, a label 
stack may be used to carry two labels when a packet is forwarded through a transit 
routing domain. The use of label stacks as opposed to single labels is well known to 
those skilled in the art and has been specified in protocol descriptions of tag switching 
and MPLS. 

The path that a labeled fi:ame or packet follows over several hops of LSRs is 
known as a Label Switched Path (LSP). An LSP is somewhat like a virtual-circuit. 
However, an LSP is not necessarily between the source and destination end points for a 
packet. Instead, an LSP starts at an ingress LSR, where a label is first assigned to a 
packet, and ends at an egress LSR, where a label is removed from a packet. 

There are two primary ways that label switched paths (LSPs) can be established in 
networks. First, each label switching router (LSR) may make independent decisions to 
assign a label to a forwarding equivalence class (FEC). After making such a decision. 
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then this LSR propagates the label assignment infonnation to its neighbor LSRs. 
Neighbor LSRs are the LSRs that are adjacent to an LSR along a label switched path 

(LSP). This type of label assignment process is known as independent control of LSP i 

establishment because the LSRs are generally making independent decisions on the 

creation of an LSP. In effect the algorithm to create LSPs is distributed through many 

LSRs. The other primary method of establishing LSPs is through ordered control. In this 

method the LSP is usually setup from ingress LSR to egress LSR in an ordered fashion. 

In ordered control of LSP establishment, a decision to create an LSP generally is not 

made by each LSR. Instead of the distributed decision to create an LSP in independent 

control, the decision to create an LSP in ordered control is usually made by a more 

centralized algorithm. This might be done at ingress and/or egress LSRs. Alternatively, 

the decision in ordered control might involve an algorithm executing on at least one 

centralized controller. 

Some label switching routers (LSRs) have the capability of selectively forwarding 
packets received with label switching headers using the forwarding algorithms of label 
sv^tching technologies, while selectively forwarding packets received without label 
switching headers using forwarding algorithms not associated with label switching 
technologies. An LSR with such functionality may revert to slower IP routing decisions 
when it receives an IP datagram without a label header. 

Some LSRs allocate labels dynamically to flows such that an initial number of IP 
datagrams below a threshold count from a source to a destination may be forwarded by an 
LSR using standard IP routing functions. Then a label will be dynamically allocated to 
the flow for all IP datagrams from the source to the destination over the threshold count 
within a certain amount of time. Further IP datagram traffic between the source and 
destination will be labeled and will be processed using the faster performance forwarding 
algorithm of label switching as opposed to the slower performance algorithm of IP 
routing. 

The performance of an LSR using such dynamic label allocation frinctions is 
somewhat similar to the performance of caches in memory architectures that store data in 
faster access locations based on the spatial or temporal locality of the data from a 
previous memory access. Spatial locality (or spatial closeness) usually implies that 
unaccessed data is likely to be accessed in the future if it is located near data that has just 
been accessed. Temporal locality (or time closeness) usually implies that data that has 
just been accessed is likely to be accessed again. For label svsdtching environments, once 
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a threshold number of packets or IP datagrams has been communicated between a source 
and destination, it is likely that more datagrams will be communicated between the source 
and destination in the future. This is the case in file transfers or web page downloads. 
Once, this threshold is met, the LSR will expend the processing overhead to create a label 
for the flow of information between the source and destination so that future transfers of 
data will utilize the faster forwarding algorithm of label switching instead of the slower 
forwarding algorithms of routing protocols such as IP. This improved performance of 
label switching is similar to the improved performance from cache memory architectures 
because data that has been cached will be handled more quickly than uncached data much 
as information flows with assigned labels will be handled more quickly than information 
flows without assigned labels. 

When the dynamic binding of labels is modified by the receipt of data to be 
forwarded in the network such as the receipt of a number of IP datagrams over a threshold 
count, the binding is known as a data-driven label binding. When the receipt of control 
information modifies the dynamic binding of labels, the binding is known as control- 
driven label binding. An LSR does not have to use data-driven label binding or control- 
driven label binding to the mutual exclusion of the other type of binding. In addition, 
there are many variations of both data-driven label binding and control-driven label 
binding. 

There are two primary ways to encode the information needed for label switching 
in a packet. First, the label switching information may be carried in a label header ^'shim" 
that is placed between layers 2 and 3 of the OSI model. The shim contains the label 
switching information and is encapsulated between a layer 2 header and a layer 3 header. 
Alternatively, the label switching information may be included in the layer 2 header of 
some protocols such as ATM and frame relay. FIG. 2 shows how label switching 
information 21 1 can be placed between the data link layer 102 and the network layer 103. 
The label switching information 21 1 usually includes short, fixed length labels to allow 
simplified and fast forwarding of packets. In addition, for some protocols, such as ATM 
and frame relay, it is possible to incorporate the label switching information into the layer 
2, data link layer addresses as show in FIG. 3, which displays the data link layer including 
label switching information as item 302. For example, in ATM the label switching 
information could be included in the Virtual Channel Identifier (VCI) field and/or in the 
Virtual Path Identifier (VPI) field in the ATM header. In frame relay the label switching 
information could be included in the Data Link Connection Identifier (DLCI) field. 
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Though some protocols can incorporate label switching information within the layer 2, 
data link addresses, it is not required that these protocols incorporate the label switching 
information within the layer 2 header. Instead, these protocols can also use the shim label 
header. Thus, the shim label header may be used with protocols such as ATM or frame 
relay. In addition, in ATM or frame relay some of the label switching inforaiation could 
be included in the layer 2 header and some could be included in a shim label header. 
Still, for efficiency reasons it is likely that protocols such as ATM and frame relay will 
use the layer 2 headers to incorporate label switching information. Furthermore, ATM 
and frame relay are only examples of two protocols that currently exist that are capable of 
incorporating label information within the layer 2 header of the protocol. Other layer 2 
protocols may exist that allow label switching information to be incorporated in the layer 
2 headers. 

FIG. 4 shows how multiple layer 2, data link protocols such as Ethemet 402a, 
token ring 402b, ATM 402c, frame relay 402d, and PPP (Point-to-Point Protocol) 402e as 
well as multiple layer 3, network protocols such as IPv6 (Internet Protocol version 6) 
403a, IPv4 (Internet Protocol version 4) 403b, IPX (Internetwork Packet eXchange 
protocol) 403c, and AppleTalk 403d can be used with a label switching layer 411. IPv4 
403b is the conunon IP protocol used in the Internet, while IPv6 403a is a newer revision 
of the IP protocol. IPX 403c is a protocol often used on Novell networks, while 
AppleTalk 403d was developed for Macintosh networks. The data link layer protocols 
and the network layer protocols of FIG. 4 are only examples. Those skilled in the art will 
be aware that many more data link and network protocols exist and may be used with 
label switching technologies such as MPLS. Multi-Protocol Label Switching (MPLS) 
was designed to be used with both multiple network layer protocols as well as multiple 
data link layer protocols. Thus, MPLS has been described as being multi-protocol both 
above and below. 

Label switching and MPLS in particular do not fit nicely in the 7-layer OSI 
model. Label switching is not a layer 2, data link level protocol because it can operate 
over many layer 2 protocols. In addition, it is not a layer 3, network level protocol 
because it does not have the common addressing and routing functions of a layer 3 
protocol. Even though label switching and MPLS violates the abstractions of the 7-layer 
OSI model, it still provides useful functionality to networks. 
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Virtual Private Networks 

One must be careful to avoid confusion between a point-to-point medium 
(discussed earlier) and the Point-to-Point Protocol (PPP) 402e shown as a layer 2, data 
link protocol in FIG. 4. Although PPP 402e was designed to provide multiple-protocol 
encapsulation over point-to-point media, the robust features of PPP 402e have been used 
and expanded to allow its use in many additional environments. Specifically, PPP 402e 
provides the capability to encapsulate many protocols and has control mechanisms to 
allow for the negotiation of settings for various other protocols. As a result of these 
features PPP 402e has been used in many tunneling protocols for virtual-private networks 
(VPN) and other uses. 

FIG. 5 shows a possible protocol stack where PPP 402e is used in a VPN. Often 
VPNs are designed to run over a public network layer 503a such as the IP network of the 
Internet. Normally, VPNs carry a private network layer 503b inside of a protocol such as 
PPP 402e. The private network layer 503b could be any network layer protocol. 
Normally the PPP 402e frames are carried in an encapsulation protocol layer 511. The 
Point-to-Point Tunneling Protocol (PPTP) is an example of an encapsulation protocol 
layer 511. PPTP is based on the Generic Routing Encapsulation (GRE) Protocol. 

FIG. 6 shows another possible protocol stack where PPP 402e is used in a VPN. 
The protocol stack in FIG. 6 includes a public network protocol 603a, a private network 
protocol 603b, a public transport protocol 604a, and a private transport protocol 604b. A 
public network protocol 603a such as IP in the Internet and a public transport protocol 
604a such as UDP may be used to carry an encapsulation protocol layer 611. Example 
encapsulation protocol layers 61 1 that would use the protocol stack of FIG. 6 include the 
Layer 2 Tunneling Protocol (L2TP) and the Layer 2 Forwarding (L2F) protocol. 

Those skilled in the art will be aware that the examples of VPNs shown in FIG. 5 
and FIG. 6 are only a small portion of the possible ways of combining protocols stacks 
for VPNs and other purposes. They are presented in this present application to show that 
there are at least two places where MPLS or other label switching information can be 
placed in the protocol stacks. Specifically, in FIG. 5 MPLS or other label switching 
information can be included between data Unk layer 102 and public network layer 503a to 
implement label switching in a public network. In addition, in FIG. 5 label switching 
information could be used between PPP 402e and private network layer 503b to 
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implement label switching in a private network that has been tunneled through the public 
network in a VPN. 

Also, in FIG- 6 MPLS or other label switching information can be included 
between data link layer 102 and public network layer 603a to implement label switching 
in a public network. In addition, in FIG. 6 label switching information could be used 
between PPP 402e and private network layer 603b to implement label switching in a 
private network that has been tunneled through the public network in a VPN. Thus, it is 
possible for private label switching information (that might exist between PPP 402e and 
private network layer 503b or 603b) to be tunneled through the Internet The examples in 
FIG. 5 and FIG. 6 are intended to suggest that the label switching information normally 
carried between data link layer 2 and network layer 3 (or in layer 2 header information) 
may occur not only above or in a data link layer 102 directly above a physical layer 101, 
but also above or in a layer such as PPP 402e that has many of the functions of a data link 
layer 102 but may be used in a way that is not directly above a physical layer 101. In any 
case, the prior use of MPLS by those skilled in the art would likely be limited to carrying 
IP datagrams or other network level traffic. This would not include MPEG because those 
skilled in the art generally would not consider MPEG transport to be a layer 3, network 
level protocol. 

MPEG Encapsulation 

The concept of encapsulation in building frames or packets for transmission is 
well known by those skilled in the art, and is important in understanding how firames or 
packets are generated for transmission and decoded in reception using a layered protocol 
model such as the OSI 7-layer model. In general, for transmission each higher level 
protocol passes information down to a lower level protocol. The information is 
enc^sulated by the lower level and further passed down to an even lower level protocol 
for further encapsulation. This process is repeated until the frame or packet is completely 
created for transmission. An inverse process of passing information up to higher level 
protocols is performed in decoding received frames or packets. Depending on the 
protocol, most protocol layers build frames or packets using a header, a payload, and an 
optional trailer or tail. Some protocols use fixed length frames or packets while other 
protocols use variable length firames or packets. For example, 10 MBPS Ethernet is a 
variable length data link level protocol with firames varying in size fi^om 64 octets to 1 5 1 8 
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octets. In contrast, ATM has a 53 octet fixed length cell. In addition, there are various 
ways of handling protocols capable of carrying variable length payloads with the two 
most common being the inclusion of a length field in the header for that protocol and the 
use of some special flag pattern to indicate the end of a variable length fi^ame or packet. 

Properly mapping information fix)m higher level protocols into lower level 
, protocols sometimes creates problems when the amount of information fi-om a higher 
level protocol does not fit the size limitations of the lower level protocol. Various 
methods are commonly known in the art for breaking large blocks of information into 
smaller blocks of information for transmission by multiple lower level protocol 
transmissions. In addition, various methods are commonly known in the art for adding 
stuffing or filling to small blocks of information to fill up the required minimum sizes of 
frames or packets. Furthermore, as packets transverse a network with different maximum 
transfer unit (MTU) sizes, the packets created for a network with a large MTU may have 
to be fragmented into smaller packets for transmission over networks with a smaller 
MTU. All these variations as well as others variations that are well known in the art for 
dealing widi encapsulation are intended to be included in the embodiments of the present 
invention. Thus, figures or explanations showing a lower protocol layer header followed 
by a payload from a higher protocol layer without any trailers or tails are not meant to 
indicate that the embodiments of the present invention will not work with protocols that 
have trailers or tails. In addition, figures or explanations showing methods of mapping 
large blocks of information into a lower level protocol without regard to the minimum 
and/or maximum size limitations of the lower level protocol are not intended to limit the 
embodiments of the present invention to only work when their is an exact fit in the size of 
the upper level mformation into the size limits of the lower level information. Therefore, 
FlGs. 7 - 11 are only intended to be example packets or frames. These figures are not 
intended to suggest any limitations with respect to methods of encapsulating higher level 
protocol information into lower level protocol information. For example, the fact that 
FIGs. 7 - 1 1 do not show tails or trailers to the frames or packets is not an indication that 
the embodiments of the present invention cannot work in environments where the frames 
or packets have tails or trailers. 

Fmthermore, with respect to FIGs. 7 - 1 1 , any references to a label or a label 
header do not mean to limit a label header to only include a label. Though the 
predominate information in a label header is often a label, other information is generally 
also contained in a label. For example, an MPLS shim header contains a 3 bit 
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experimental field, a 1 bit stack field, an 8 bit Time-to-Live (TTL) field, and one or more 
20 bit labels in a label stack. Also, multiple label shim headers might be used within a 
single label switched frame for additional flexibility. 

For datagram packet data networks, MPEG has generally been encapstilated inside 
a network layer protocol such as IP. FIG; 7 shows an example of how MPEG may be 
encapsulated in IP in a label switched fi-ame. The label switched frame would include a 
header with layer 2 addressing 702, an IP network layer 703, and an MPEG transport 
packet in the payload of an IP datagram 704. The label 71 1 for label switching would be 
carried between the header with layer 2 addressing 702 and the header for the IP network 
layer 703. Often additional protocols such as the user datagram protocol (UDP) may be 
used between IP network layer 703 and the MPEG transport packet. Thus, the MPEG 
transport packet may be encapsulated within other protocols, such as UDP, which are 
then encapsulated inside the payload of an IP datagram 704. 

Similarly for protocols such as ATM or frame relay that have the capability of 
including labels within the layer 2 header, FIG. 8 shows how MPEG is commonly 
encapsulated in IP in a label switched frame. The label switched frame would include an 
ATM or frame relay header incorporating a label within the layer 2 addressing fields 802, 
an IP network layer 803, and an MPEG transport packet in the payload of an IP datagram 
804. 

In addition to encapsulating MPEG in an IP datagram, MPEG has been 
encapsulated in ATM cells for virtual-circuit packet networks. FIG. 9 shows how an 
ATM or frame relay header 902 might encapsulate an MPEG transport packet in the 
payload of ATM cells of fi-ame relay frames. For ATM this configuration for MPEG has 
been used for PVCs or SVCs using a Q.293 1 as a layer 3 protocol to establish SVCs. 
Thus, the layer 2 ATM header encapsulates an MPEG transport packet while Q.293 1 is 
used as a layer 3 protocol with layer 3 addresses to set up the ATM virtual circuits to 
carry the ATM cells. 

Though some protocols such as ATM and frame relay are inherently label 
swapping or switching protocols, the prior use of MPEG transport over ATM frames was 
not generalized to work over many label switching protocols. In addition, ATM normally 
uses fixed PVCs or Q.293 1 for SVCs to establish end-to-end virtual circuits between 
MPEG source and destination devices. Furthermore, the MPEG source and destination 
devices would usually be connected to ATM switches through point-to-point media. 
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In contrast, the preferred embodiments of the present invention work over other 
label switching protocols besides ATM. In general, the preferred embodiments of the 
present invention work over MPLS (Multi-Protocol Label Switching) or other label 
switching protocols capable of natively or directly carrying MPEG transport, for example. 
The multi-protocol below capability of MPLS means that in the preferred embodiments of 
the present invention MPEG may be carried in MPLS over other layer 2 protocols besides 
ATM and frame relay. In addition, in the preferred embodiments of the present invention 
the label switched paths (LSPs) are not necessarily end-to-end connections between 
MPEG devices as in the case of the PVCs and SVCs of ATM and frame relay. 
Furthermore, in the preferred embodiments of the present invention the labels in general 
label switching may be distributed by various protocols described below, while the. header 
addresses (i.e., VCI and VPI) of ATM are fixed for PVCs and setup using Q.293 1 for 
SVCs. Also, the LSPs of the preferred embodiments of the present invention may 
terminate into shared or contention-based media with multiple attached MPEG devices as 
opposed to the point-to-point link termination of ATM PVCs or SVCs into a single 
MPEG device. In most cable TV networks that are the probable deployment environment 
of the preferred embodiments of the present invention, the LSPs may terminate at 
broadcast or multi-point media capable of being connected to many MPEG-capable 
subscriber devices. 

FIG. 10 shows an embodiment of the present invention. In FIG. 10 an MPEG 
transport packet 1 000 is encapsulated directly inside a label switched payload. The 
packet in FIG. 10 further comprises a header with layer 2 addressing 1002 and a label 
header 101 1. FIG. 1 1 shows another embodiment wherein an MPEG transport packet 
1 1 00 is encapsulated directly inside a label switched payload found inside an ATM or 
frame relay header that incorporates a label within the layer 2 header 1 1 02. One major 
difference in FIG. 1 1 from prior implementations is that the LSPs of the preferred 
embodiments of the present invention may be established by other protocols than the 
ATM layer 3 connection signaling protocol of Q.293 1 that sets up ATM switched virtual 
circuits to carry ATM cells with MPEG payloads. These protocols for establishing LSPs 
and distributing labels will be discussed in more detail below. Also, FIGs. 10 and 1 1 are 
not meant to suggest that one and only one MPEG transport packet may be encapsulated 
into one label switched frame. The embodiments of the present invention could also 
work, for example, and without limitation, if multiple MPEG transport packets and/or 
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fractions of one MPEG transport packet are encapsulated into a single label switched 
frame. 

Implementing Label Switching 

FIG. 12 shows the common functions of standard routers. These functions can be 
broken down into a forwarding component 1201 and a control component 1202. The 
forwarding component 1201 generally contains rules for deciding how to forward packets 
121 1. In general, these rules specify what information in an incoming packet should be 
evaluated and compared to a forwarding table to decide how to forward an incoming 
packet. Unfortunately, in routers these rules became more and more complex to handle 
different types of packets and forwarding models. Some examples of forwarding models 
and rules for IP routers include: forwarding rules for imicast 1215, forwarding rules for 
multicast 1216, and forwarding rules for unicast with type of service (TOS) flags 1217. 
As an example, the common forwarding rule for unicast IP packets generally involves a 
longest match algorithm that matches the destination address of incoming packets with 
the entry in the forwarding table that has the longest bit length match of the destination 
address. 

The control component 1202 of routers normally maintains the forwarding table 
used by the forwarding component 1201. The maintenance of this table often requires a 
protocol to distribute consistent information about the network among multiple routers. 
Thus, the control component normally includes procedures for maintaining and updating 
the forwarding table 1222. Examples of some common routing protocols that distribute 
information on routing or forwarding tables include RIP (Routing Information Protocol) 
1225, OSPF (Open Shortest Path First) 1226, BGP (Border Gateway Protocol) 1227, and 
PIM (Protocol Independent Multicast) 1228. Those skilled in the art will realize that 
these examples are only a small number of the routing protocols that exist. 

FIG. 13 shows the functions of a label switching router (LSR), which is used in 
label switching networks instead of or in addition to standard routers. In an LSR, the 
forwarding component 1301 and the control component 1302 have been separated into 
two distinct functions. This separation of functions allows simplification of the 
forwarding component 1 301 so that it may more easily be implemented in a fast, all- 
hardware solution. In the forwarding component 1301, the rules for deciding how to 
forward packets 1311 have been reduced to one simple rule, exactly match an incoming 
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label to a label switching forwarding table 1315. This rule can often be implemented in a 
simple, indexed lookup table. Thus, the forwarding table is simplified. In an LSR the 
control component 1 302 must still have procedures for maintaining and updating the 
forwarding table 1322. These procedures can be broken down into three major tasks: 
path determination 1325, label assignment 1335, and label distribution. 

Path determination normally involves performing a mapping bom a forwarding 
equivalence class (FEC) to a next hop {i.e. , a next router or LSR where the packet is 
forwarded to). For the IP protocol a network layer routing protocol such as RIP, OSPF, 
BGP, or PIM usually determines the next hop. For example, a simple non-label switched 
network might use RIP version 2 (RIPv2) as a routing protocol. RIPv2 is well known in 
the art and is used for routing in simple for IPv4 networks. The following description of 
RIPv2 covers the usual function of RIPv2 in routed IP networks that may not be using 
label switching even though the description of the function of RIPv2 is explained by 
terminology such as forwarding equivalence class (FEC) that is used in label switching 
networks. RIPv2 packets carry a list of IP network addresses identified by a 32-bit 
address and a 32-bit mask. In addition, in a RIPv2 packet each IP network address in the 
list is associated with a next hop IP address and a hop count. The IP network addresses 
identified by a 32-bit address and a 32-bit mask are basically a forwarding equivalence 
class (FEC) such that all IP packets whose destination address field falls within the range 
specified by an IP network address are forwarded equivalently. An IP packet that 
matches a forwarding equivalence class (FEC) is forwarded to a next hop router 
associated with that FEC. The IP address of the next hop router is specified as the next 
hop IP address in the RIPv2 packet. The hop count specifies the number of routers that 
must be transversed before a packet forwarded to the next hop router will reach the IP 
network specified by the FEC. 

As the evolution of networks, especially from the development of fiber optics, has 
increased transport bandwidth relative to switching bandwidth, it becomes less expensive 
to carry all traffic and let the destination select the information it wants to receive as 
opposed to using switching technology to control the information allowed on the transport 
network. This type of network is similar to broadcast environments on satellite or cable 
networks, where a signal is sent to all or most users, but access to the signal is 
conditional. This type of network is much more deterministic than IP networks. Usually 
centralized entities determine what content is put on the network and who may have 
access to the content. For a system where most of the content is transported across the 
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network to the destination and access to the content is conditional, path determination is 
unlike the path discovery process used in routing protocols such as for IP. Instead the 
centralized entity must know the topology of the network and enable the proper paths. As 
part of the preferred embodiments of the present invention, a centralized system might 
determine paths during the label assignment process. 

The other two control functions generally used in a label switching environment 
are label assignment, which includes procedures for creating bindings between labels and 
FECs, and label distribution, which includes procedures for distributing label binding 
information. Together these two functions work to establish and distribute FEC to label 
mappings. In many label switching technologies including some of the proposals for 
MPLS, explicitiy routed label switched paths (LSPs) are envisioned for policy routing 
and traffic engineering. The preferred embodiments of the present invention propose to 
further use LSPs to set up broadcast and personal television paths for MPEG transport. 
To implement such a system for MPEG delivery, at least one centralized controller can 
accomplish the function of creating paths and assigning labels. An example of a 
centralized controller that could be utilized to implement such a system is the Digital 
Network Control System*s (DNCS) Session and Resource Manager (SRM) as used in 
Scientific-Atlanta's Digital Broadcast Delivery System (DBDS). The DNCS SRM may 
implement the functions of an MPEG Digital Storage Media-Command and Control 
Session and Resource Manager (DSM-CC SRM), which among other things manages and 

controls MPEG sessions. 

All references in this application to one or at least one centralized controller are 
not intended to be limiting as those skilled in the art will be aware that there may be 
requirements for multiple centralized controllers for redundancy and/or scaling reasons. 
In addition, those skilled in the art will be aware that the functions of a central controller 
may be distributed among multiple processors in multiple network devices to achieve 
similar or equivalent functionality. 

The at least one centralized controller could base label assignments on 
information associated with MPEG transport packets whose format is described below. 
For instance, an entire MPEG transport stream might need to transverse the same label 
switched path (LSP), be bound for the same destination, and have identical quality of 
service (QoS) requirements. In such a situation all the MPEG programs in the transport 
stream are part of the same forwarding equivalence class (FEC). This FEC would be 
given an MPLS label that would designate the entire transport stream including more than 
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one MPEG program and the associated program specific information (PSI)» This method 
of label assignment would be useful for transporting MPEG streams over a channel that 
may contain more than one MPEG transport stream because the MPEG packet IDs (PIDs) 
in MPEG transport packets are only unique over one MPEG transport stream. MPLS or 
other label switching technologies could be used to allow MPEG transport packets with 
identical PIDs but belonging to different MPEG transport streams to be time-division 
multiplexed into the same channel or medium. With MPLS or other label switching 
technology, multijple MPEG transport streams could be multiplexed into a channel so that 
a first label could be assigned to a first MPEG transport stream that includes a first 
Program Association Table (PAT) with MPEG PID = 0, and a second, different label 
could be assigned to a second MPEG transport stream that includes a second Program 
Association Table (PAT) with the same MPEG PID = 0. The Program Association Table 
(PAT) is only one example of two MPLS or other label switching forwarding equivalence 
classes (FECs) carrying two different MPEG transport packets that might have the same 
PID number. The use of PID = 0 in the preceding example is not meant to be a limitation 
on the MPEG PIDs that may be used in the two different MPEG transport streams carried 
in two different forwarding equivalence classes of a label sv^tching network. Thus, the 
advantage of using MPLS or other label switching technology to carry two or more 
MPEG transport streams will work to differentiate MPEG transport packets belonging to 
different MPEG transport streams even though the MPEG transport packets have the 
same PID values. These same PID values for MPEG transport packets belonging to 
different MPEG transport streams may be any PID value including the PID = 0 of a 
Program Association Table (PAT) as well as any other PID value. 

If a label switched path (LSP) extends all the way to a subscriber device, MPLS 
labeled transport streams could group the same programs that are normally provided in a 
frequency-division multiplexed (EDM) channel in cable TV systems. This in effect 
enables an evolution firom the current broadband, FDM cable TV system to a full 
baseband, transport cable TV system. In such a network, an MPLS preselector or switch 
might replace the RF tuner found in current subscriber devices for FDM cable TV 
systems. This would allow existing MPEG transport engines to operate with baseband 
streams capable of much higher data rates than individual FDM channels. 

Also, an MPLS label could be applied to one MPEG program that is part of an 
MPEG transport stream. This in effect creates a one-program MPEG transport stream 
and requires program specific information (PSI) for each program. This type of 
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assignment might be useful for unicast cases where individual subscribers desire stream 
control so that only one program falls in a forwarding equivalence class (FEC). 

Furthermore, MPEG transport packet IDs (PIDs) identify particular flows of 
information such as a video program stream. These PIDs could be used by and/or 
assigned by at least one centralized controller as part of the label assignment function. In 
addition, the stream ID found in the header of an MPEG packetized elementary stream 
(PES) also might be used by at least one central controller as part of the label assignment 
process. In contrast to typical IP routing that is based on destination IP addresses, these 
identifiers {Le., the PID and the stream ID) in MPEG packets are more closely related to 
the source or content of a stream of MPEG data. 

These label assignment functions available in MPLS or other similarly capable 
label switching technologies simplify merging streams of information that were 
previously dissimilar. MPEG transport already allows merging two MPEG streams to 
create a new MPEG stream. This type of merge might be done to merge an MPEG 
stream of normal program content with an MPEG stream of advertising content. MPEG 
transport also allows merging MPEG streams with private data streams that might contain 
IP datagrams. With MPLS or other similarly capable label switching technology, 
additional multiplexing and merging techniques are possible. For example, multiple 
MPEG program streams with different PIDs could be merged into one MPLS forwarding 
equivalence class (FEC) that contains two MPEG programs, which share the same MPLS 
label. In addition, it would be possible to use a single label to merge an MPEG stream 
with an IP datagram stream as one FEC with one label. Either the MPEG stream or the IP 
stream may contain normal program content while either the IP stream or the MPEG 
stream, respectively, may contain the advertising content. Also, it would be possible to 
use separate labels for the advertising stream and the program stream and have the 
subscriber device receive both streams. The advertising stream and the program stream 
may be either MPEG or IP. These previous multiplexing examples are not intended to 
limit the scope of the present invention in any way. Given the present disclosure, those 
skilled in the art will be aware that many possible ways exist for combining and 
multiplexing MPEG streams using label switching technologies such as MPLS. 

The last main control function needed in label switching environments is label 
distribution. Label distribution involves informing label switching routers (LSRs) of 
label assignments by distributing the label binding information over communication 
paths. MPLS does not specify a required protocol for distributing labels so there are 



-25 



wo 02/052864 



PCTAJSOl/44264 



various proposals for label distribution. One proposed method is to distribute label 
assignment information with the routing protocols by including the information in the 
packets of RIP, OSPF, BGP, etc. Another proposed method is to use the Resource 
Reservation Protocol (RSVP) to distribute labels. RSVP was primarily designed for 
informing network equipment about information flows in an IP network. Once informed 
about information flows by RSVP, the network equipment may allocate resources to 
information flows in order to implement various quality of service (QoS) criteria for an 
information flow. The use of RSVP as a label distribution protocol might allow label 
switched paths (LSPs) to be established in a network based on QoS criteria. RSVP is 
basically a signaling protocol for establishing QoS for integrated services over IP- 
oriented networks. Also, the IETF has developed a new protocol for label distribution 
called the Label Distribution Protocol (LDP) that is more generalized and less IP-centric 
than RSVP. 

Constraint-based routing is one way to provide quality of service in a label 
switched network by determining suitable routes vdth the network resources to meet a 
variety of constraints such as a minimum bandwidth. The Constraint-based Routing 
Label Distribution Protocol (CR-LDP) is an extended version of LDP that enables 
constraint-based routing and QoS reservation in label switching networks such as an 
MPLS network. 

The preferred embodiments of the present invention propose to use the MPEG 
Digital Storage Media-Command and Control (DSM-CC) protocol for label distribution 
to MPEG-aware devices such as MPEG-aware LSRs. Label distribution using DSM-CC 
may occur as part of the process of setting up DSM-CC sessions. DSM-CC is an MPEG 
protocol specification for signaling MPEG sessions. DSM-CC consists of two main 
protocols: 1) a DSM-CC user-network signaling protocol and 2) a DSM-CC user-user 
signaling protocol. The DSM-CC user-network protocol is designed to signal the 
network to setup MPEG sessions for MPEG user devices. MPEG user devices include 
subscriber terminal equipment, which might initiate the download of an MPEG movie. 
Also, MPEG user equipment includes MPEG video or audio servers, which may initiate 
the download of MPEG information to subscriber devices. The MPEG DSM-CC user- 
network protocol is somewhat similar to common layer 3 signaling protocols such as 
Q.931 used for circuit-switched connection establishment in narrowband ISDN or Q.2931 
used for switched virtual-circuit establishment in ATM. Q.2931 is basically an extended 
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version of Q.93 1 to provide for more sophisticated quality-of-service requirements than 
are possible in Q.93 1 . 

However, DSM-CC was not really designed to initiate network setups. Instead, if 
MPEG devices are connected to a circuit switched network, then Q.931 might be used to 
establish circuit-switched connections between MPEG devices. Next, DSM-CC user- 
network signaling would establish the MPEG video or audio sessions between MPEG 
user devices over the circuit-switched paths. Alternatively, if MPEG devices are 
connected to an ATM packet-switched, virtual-circuit network, then Q.293 1 might be 
used to establish SVCs between MPEG devices. Next, DSM-CC user-network signaling 
would establish the MPEG video or audio sessions between MPEG user devices over the 
SVCs. The DSM-CC user-user protocol is designed to send control information between 
MPEG user devices. Thus, the DSM-CC user-user protocol may used by an MPEG 
subscriber device to control a video flow &om an MPEG video source. The subscriber 
device may be able to use VCR-like functional control to pause, rewind, or fast-forward 
video from an MPEG video source using the DSM-CC user-user protocol. 

The DSM-CC standard covers various types of sessions such as Continuous Feed 
Sessions (CPS) and Exclusive Sessions (£S). In addition, the DSM-CC standard covers 
user to network (UN) messages that generally create a user-network protocol as well as 
user to user (UU) messages that generally create a user-user protocol. Presently the 
DSM-CC standard does not define network to network messages. If an external server 
wants to set up a continuous feed session (CPS), then it uses one or more user to network 
(UN) messages. Similarly, if an external client wants to create an exclusive session (ES), 
then it also uses one or more user to network (UN) messages. If a client wants to control 
a server, then one or more user to user (UU) messages are conununicated. 

When establishing DSM-CC sessions, allocation of resources in the network may 
be accomplished through the communication of other protocols besides DSM-CC. For 
example, if the network wishes to set up a continuous feed session (CFS) between an 
MPEG client and an MPEG server, then various non-DSM-CC messages may be used to 
establish the CFS. The protocols carrying these messages might include remote 
procedure call (RPC) and/or simple network management protocol (SNMP) as examples 
of protocols that may be used to communicate resource allocations in a CATV network 
between equipment such as a controller and a modulator. These additional protocol 
messages might also be used to distribute labels during the process of setting up and 
managing DSM-CC sessions. Those skilled in the art will be aware that RPC and SNMP 
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are just examples of possible protocols that might be used in the label distribution, and the 
embodiments of the present invention are not intended to be limited to those protocols. 
Thxis, the labels may be distributed in DSM-CC messages or other non-DSM-CC 
protocols as part of the process of establishing DSM-CC sessions. 

Furthermore, other label distribution protocols such as LDP, CR-LDP, and/or 
RSVP could be used to distribute labels to non-MPEG-aware network equipment (e.g. , 
LSRs) in a label switching network. Although those skilled in the art will be aware that 
other protocols also may be used, the preferred embodiments of the present invention 
propose that the label distribution messages for MPEG DSM-CC and other protocols for 
label distribution may be carried in IP datagrams because of the generaUy ubiquitous 
nature of basic IP functionality in network devices. Basic IP functionality is often 
included in network devices to allow such common capabilities as network management. 
Still, the embodiments of the present invention are in no way limited to only distributing 
label information in IP datagrams. 

In the embodiments of the present invention, standard IP messages may be used to 
implement the MPLS control component functions of path or route determination, label 
assignment, and label distribution. Thus, the devices and methods of the embodiments of 
the present invention may be used in a network that carries IP network level traffic. 
However, the embodiments of the present invention make it possible to carry MPEG 
transport packets directly within MPLS or other label switched technology without the 
necessity of placing the MPEG transport packets inside IP datagrams or other network 
level protocol messages. 

MPEG Transport Packets 

MPEG, the Motion Pictures Expert Group, has established standard procedures for 
encoding information streams including real-time video and audio. Furthermore, some of 
these standards include protocols for the transport and signaling of information flows. 
This present application has been written mainly based on some of the MPEG-2 
standards. However, this is not meant to indicate any limitations on the present invention. 
Thus, it is expected that the preferred embodiments of the present invention will work 
without limitation with MPEG-1, MPEG-2, MPEG-4, MPEG-7, and MPEG-21 as well as 
MPEG and non-MPEG standards to handle real-time information flows that may be 
developed in the future. 
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MPEG-2 includes a Systems Specification 1401 that defines some of the 
interfaces for MPEG packets as shown in FIG. 14. FIG. 14 shows one interface of the 
MPEG Systems Specification 1401 as the dashed line 1405. Video data 1415 goes 
through video encoder 1417 into the MPEG systems specification 140L This MPEG 
encoded video fix)m video encoder 1417 is output on connection 1419 and is input into 
packetizer 1421 to create a video packetized elementary stream (PES) 1425. In addition, 
FIG. 14 shows audio data 1435 going through audio encoder 1437 into MPEG systems 
specification 1401 . This MPEG encoded audio firom audio encoder 1437 is output on 
connection 1439 and is input into packetizer 1441 to create audio packetized elementary 
stream (PES) 1445. Video PES 1425 is combined with audio PES 1445 in MPEG 
program stream mux (or multiplexer) 1455 to create MPEG program stream 1465. 
Furthermore, video PES 1425 is combined with audio PES 1445 in MPEG transport 
stream mux (or multiplexer) 1475 to create MPEG transport stream 1485. 

An MPEG elementary stream is an output fi-om an audio or video encoder. Before 
communicating this MPEG elementary stream, it must be packetized into a packetized 
elementary stream (PES). MPEG systems specification 1401 comprises rules for creating 
MPEG program streams 1465 and MPEG transport streams 1485. MPEG program 
streams 1465 include information to carry a single MPEG program. An MPEG program 
comprises different PES streams that share a common time base. For example, an MPEG 
movie may include a video PES, an English audio track, and a Spanish audio track all as 
one program. The MPEG program stream 1465 from MPEG program stream multiplexer 
1455 is designed to allow local delivery of MPEG programs to players such as a VCR- 
like unit playing a movie on a locally connected TV. The MPEG transport stream 1485 
from MPEG transport stream multiplexer 1475 is designed to allow delivery of MPEG 
programs across communication networks in MPEG transport packets. The MPEG 
transport protocol is designed to carry one or more MPEG programs and to communicate 
the programs in MPEG transport packets. In addition to carrying packetized elementary 
streams (PES), the MPEG program and the MPEG transport specifications are designed 
to cany additional information such as private data, time synchronization information, 
and service and control information. An example of private data might be closed 

■ 

captioning for an MPEG movie. The private data portion of MPEG transport may even 
carry IP datagrams. 

FIG. 15 shows how elementary streams of video are placed in packetized 
elementary streams (PES) and MPEG transport packets. Elementary stream 1 505 is an I- 
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Picture, which is an encoded "intra" frame of video that is part of the algorithm used in 
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MPEG video compression. Elementary stream 1506 is a P-Picture, which is an encoded 
"predictive" frame of video that is part of the algorithm used in MPEG video 
compression. Nothing in this application is intended to limit the embodiments of the 
present invention only to methods of digitizing and compressing audio or video data that 
are currently described in MPEG specifications. Thus, other digitizing and/or 
compression algorithms than those in MPEG specifications might also be used, and the 
MPEG I-Picture/P-Picture compression algorithm is only an example. In FIG. 1 5 the I- 
Picture elementary stream 150S is packetized into a packetized elementary stream (PES) 
comprising PES Header 1515 and PES Data 1516, which includes the data from the I- 
picture frame 1505. The P-Picture elementary stream 1506 is packetized into a 
packetized elementary stream (PES) comprising PES Header 1525 and PES Data 1526, 
which includes the data from the P-picture frame 1506. The packets of a PES include a 
stream ID in the header of PES packets. These stream IDs allow determination of the 
type of information contained in a PES packet. 

FIG. 15 frmher shows how one variable length PES packet comprising PES 
header 1515 and PES packet payload 1516 and containing data from an I-picture 
elementary stream is encapsulated into several fixed length MPEG transport stream 
packets. MPEG transport stream packet with transport stream header 1 535 contains an 
MPEG transport stream packet payload 1536 encapsulating PES header 1515 and the first 
part of the packetized data from the I-Picture 1516. MPEG transport stream packet with 
transport stream header 1 545 contains an MPEG transport stream packet payload 1 546 
encapsulating the second part of the packetized data from the I-Picture 1516. Finally, 
MPEG transport stream packet with transport stream header 1 555 contains an MPEG 
transport stream packet payload 1556 encapsulating the final part of the packetized data 
from the I-Picture 1516 as well as stuffing bits to fill out the MPEG transport packet to its 
fixed length size. 

The MPEG transport stream packet header includes a 1 3 bit field known as a 
packet ID or PID that is used to identify information in the MPEG transport multiplexing 
hierarchy. This PID field can include values from 0 to 2^^ - 1 or 8191 (decimal). Some 
of the PID values such as 0 and 1 are assigned to specific tables. PID values 2 to 1 5 
(decimal) are reserved for fiiture use. PID value 8191 (decimal) designates a null packet, 
while PID values 16 to 8190 (decunal) are available for PES streams, map tables, and 
network tables. 
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FIG. 16 shows an example of how the muhiplexing architecture of MPEG 
transport works. MPEG transport packets with PID = 0 carry a Program Association 
Table (PAT) 1605 that contains a list of MPEG programs associated with other PID 
values. MPEG transport packets with PID = 1 carry a Conditional Access Table 1615 
that is used to limit access to restricted and encrypted programs such as in a pay-per-view 
service. The first entry in the Program Association Table 1605 associates program 0 with 
PID 20. This means that MPEG transport packets with PID = 20 contain a Network 
Information Table (NIT) 1625. The Network Information Table (NIT) 1625 contains 
information about the network properties of the network carrying the MPEG transport 
packets. The Network Information Table (NIT) 1625 is generally associated with 

i 

program 0 in the Program Association Table (PAT) 1605. Program Association Table 
(PAT) 1605 further shows an example of three MPEG programs: program 1, program 22, 
and program 35. 

From the Program Association Table (PAT) 1605, MPEG multiplexers/ 
demultiplexers can determine that for MPEG program 1 the Program Map Table (PMT) 
1635 may be found in MPEG transport packets with PID = 68. As shown in FIG. 16, 
Program Map Table 1635 for program 1 contains a table listing the Packetized 
Elementary Streams (PES) included in program 1. For Program Map Table 1635 the first 
PES stream is a video stream and can be foimd in MPEG transport packets with PID = 
190 as shown as PES 1637. In addition, for Program Map Table 1 635 the second PES 
stream is an audio stream and can be found in MPEG transport packets with PID = 41 7 as 
shown as PES 1639. 

Also, firom the Program Association Table (PAT) 1605, MPEG multiplexers/ 
demultiplexers can determine that for MPEG program 22 the Program Map Table (PMT) 
1645 may be found in MPEG transport packets with PID = 150. As shown in FIG. 16, 
Program Map Table 1645 for program 22 contains a table listing the Packetized 
Elementary Streams (PES) included in program 22. For Program Map Table 1645 the 
first PES stream is a video stream and can be found in MPEG transport packets with PID 
= 75 as shown as PES 1647. In addition, for Program Map Table 1645 the second PES 
stream is an audio stream and can be found in MPEG transport packets with PID = 235 as 
shown as PES 1649. Finally, for Program Map Table 1645 the third PES stream is a 
private data stream and can be found in MPEG transport packets with PID = 512 as 
shown as PES 1651. 
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Furthermore, from the Program Association Table (PAT) 1605, MPEG 
multiplexers/demultiplexers can determine that for MPEG program 35 the Program Map 
Table (PMT) 1655 may be found in MPEG transport packets with PID = 184. As shown 
in FIG. 16, Program Map Table 1655 for program 35 contains a table listing the 
Packetized Elementary Streams (PES) included in program 35. For Program Map Table 
1655 the first PES stream is a video stream and can be foimd in MPEG transport packets 
vdth PID = 34 as shown as PES 1657. In addition, for Program Map Table 1655 the 
second PES stream is an audio stream and can be foimd in MPEG transport packets with 
PID = 200 as shown as PES 1659. Finally, for Program Map Table 1645 the third PES 
stream is an audio stream and can be found in MPEG transport packets with PID = 251 as 
shown as PES 1661 . 
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CATV Network 



FIG. 17 shows an example of how a CATV network might utilize MPEG transport 
packets in a label switching header. The network of FIG. 17 is only meant to be one 
example of the many possible networks. Those skilled in the art will be aware of 
additional implementations, which are intended to be included in the present invention. 
Some of the equipment in the network of FIG. 17 would be MPEG-aware (i.e., capable of 
interpreting MPEG transport packets within the label switching header) while other 
equipment may not be able to directly decode MPEG transport packets (/.e., be non- 
MPEG-aware). For instance. Label Switching Router (LSR) 1705 would likely be 
located at a headend or a central office (CO). LSR 1 705 would be MPEG-aware and take 
input from co-located MPEG source 1707 or co-located storage 1709 that may have 
stored or cached MPEG programs. In addition, other MPEG sources such as MPEG 
source 1711 may be connected to LSR 1 705 through various networks such as long 
distance delivery network 1715. The long distance network 1715 may or may not be 
MPEG-aware. The long distance delivery network 1715 may be made up of other label 
switching routers, SONET rings, or a virtual private network with a guaranteed quality of 
service that is tunneled through the public Internet. These are just some examples of 
delivery networks that may be used to implement long distance delivery network 1715, 
and none of these examples is intended to limit the present invention in any way. 

Label Switching Router (LSR) 1 705 would be further connected to a local 
delivery network 1 725. One example, without limitation, of a delivery network is 
described in U.S. Patent Application entitled "A System Architecture For Customized 
CATV Services," by Luis A. Rovira, Lorenzo Bombelli, Paul Connolly, Donald L. Sipes, 
Jr., and Douglas Woodhead, filed on the same day as the present application with 
Attomey Docket No. A-6551, and is hereby incorporated by reference in its entirety. 
This network would connect LSR 1705 to other MPEG-aware LSRs such as LSR 1735. 
In addition, the network would work with non-MPEG-aware LSRs such as LSR 1 745, 
which is also connected to local delivery network 1725. MPEG-aware LSR 1735 could 
be connected in a first distribution hub to distribution interface 1755, which may be 
MPEG-aware and which is further connected to subscriber distribution network 1757. 
Subscriber device 1 765 is an example of an MPEG-aware device connected to subscriber 
distribution network 1757. Non-MPEG-aware LSR 1745 could be connected in a second 
distribution hub to distribution interface 1775, which may be MPEG-aware and which is 
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further connected to subscriber distribution network 1 777. Subscriber device 1 785 is an 
example of an MPEG-aware device connected to subscriber distribution network 1 777. 
Finally, MPEG-aware LSR 1705 would be connected to an MPEG Digital Storage 
Medium-Command and Control (DSM-CC) Session and Resource Management (SRM) 
server 1795, which would also likely be co-located at a headend or central office (CO). 

The DSM-CC SRM server 1795 can be used for managing MPEG session 
establishment and session release. The DSM-CC protocol can be used to distribute labels 
to MPEG-aware LSRs 1705 and 1735. Other label distribution protocols such as LDP 
(Label Distribution Protocol), CR-LDP (Constraint-based Routing-LDP), and/or RSVP 
(Resource ReSerVation Protocol) can be used to distribute labels to non-MPEG-aware 
LSRs such as LSR 1745. 

Example Applications for the Present Invention 

It is expected that the preferred embodiments of the present invention will allow 
simpler deployment of many new services over the cable TV network. Some of these 
new services involve the use of subscriber-customized information. A new set of services 
known generally as personal TV is a non-limiting example of how subscriber-customized 
information might use the enhanced network capabilities resulting from the preferred 
embodiments of the present invention. Personal TV encompasses at least five basic 
functions or abilities. A first function of personal TV might be broadcast-on-demand or 
MPEG multicast, which involves the ability to deliver, simultaneously to multiple 
subscribers who request it, content that is not broadcast to all subscribers or does not 
occupy the broadcast portion of the CATV spectrum. Another fimction of personal TV 
might be the ability to deliver stored content on demand from a number of storage 
locations. This function is often called video-on-demand (VOD), but it may encompass 
other types of programs besides movie videos. A third function of personal TV might be 
the ability to retrieve broadcast content whose simultaneous broadcast time has already 
passed. Although this time shifting function could be implemented by a subscriber's 
customer premise equipment (CPE) such as a video cassette recorder (VCR) or other 
form of personal video recorder (PVR), providing this capability with equipment in the 
network allows a subscriber to watch a previously broadcast program even though the 
subscriber did not previously anticipate the need to record the content. A fourth function 
of personal TV might be the ability of subscribers to exercise control over broadcast 
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Streams, which may include VCR-like features of pause and replay. These features could 
be implemented by creating a imicast stream for a subscriber or user that has initiated a 
pause or replay request. A fifth function of personal TV might be the ability to insert 
targeted or customized advertising into streams. 

Such customized advertising screens may be carried in IP datagrams or in other 
existing or yet to be developed protocols. The ability to layer conununication protocols 
means that the IP datagrams may be delivered to user devices through many methods. 
One example includes delivering the IP datagrams in packets without label switching 
headers. Another example may be delivering IP datagrams in packets with label 
switching headers. As discussed above, some LSRs dynamically allocate labels to IP 
datagram flows based upon the number of IP datagrams reaching a threshold count in a 
specified amount of time. In the case of dynamically allocated labels, the IP datagrams 
may or may not be carried in label switched frames. Also, even if labels are not allocated 
dynamically to flows of IP datagrams, the IP datagrams may or may not be carried in 
label switched frames. In addition, IP datagrams might be carried in the private data 
streams of MPEG transport packets. None of these examples of carrying IP datagrams 
are intended to be limiting in any way. They are only meant as examples of how IP 
datagrams may be multiplexed with MPEG transport in at least one embodiment of the 
present invention, which involves natively or directly carrying MPEG transport packets 
inside of label switched frames such as the frames of MPLS. 

FIG. 1 7 will be referenced in the explanation of the following examples. Also, 
MPLS will be assumed to be the label switching protocol used by local delivery network 
1725. However, the techniques of the present invention are not necessarily limited to 
MPLS. Thus, other label switching protocols capable of carrying MPEG might also be 
used. As an example of operation of the preferred embodiments of the present invention, 
assume that the headend or CO system operator has identified content from MPEG source 
1707 or MPEG source 1711 that should be delivered to subscriber device 1765 on 
subscriber distribution network 1757. If the content is to be placed on the broadcast or 
narrowcast portion of distribution network 1757, then label switching of MPEG transport 
as described in the preferred embodiments of the present invention is not required. 
Instead MPEG would be broadcast as normally done for carrying multiple channels to 
subscriber locations such as through current FDM and TDM techniques in the cable 
network. However, if the content from MPEG source 1707 or MPEG source 171 1 is to 
implement a personal TV service such as broadcast-on-demand, then the content will be 
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switched by and/or pass through at least some of the LSRs of local delivery network 
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1725. LSR 1735 is an MPEG-aware label switching router that is specifically designed 
for interpreting and acting on MPEG transport in MPLS. In contrast, LSR 1745 is an 
MPLS compliant label switching router that is neither aware of nor capable of acting on 
the MPEG content within the MPLS frames. 

The MPEG packets may only be addressed to subscribers who request the content, 
but many subscribers may want to view this content in real-time, simultaneously with the 
subscribers that requested the broadcast-on-demand. The operator may use the DSM-CC 
Session and Resource Manager (SRM) 1795 to preconfigure sessions; thus establishing a 
path and the required resources to deliver this content to the subscribers on subscriber 
distribution network 1757. Such a preconfiguration would be done by establishing a 
DSM-CC Continuous Feed (CF) session. Subscribers on subscriber distribution network 
1757 may use a DSM-CC Client Session Setup Request to connect to this service and to 
be bound to the existing CF session. Also, the conditional access (CA) process from the 
MPEG transport Conditional Access Table (CAT) may be activated to ensure proper 
authorization to decrypt the broadcast-on-demand content. Use of the conditional access 
table in a network is optional and does not have to be implemented to obtain the benefits 
of the embodiments of the present invention. 

Suppose that subscriber device 1785 on subscriber distribution network 1777 now 
wants to receive the same content and issues a DSM-CC Session Setup Request. Because 
the content would be simultaneously delivered to other subscribers on subscriber 
distribution network 1777 who may request the content, a second Continuous Feed (CF) 
session is set up involving distribution interface 1775 and non-MPEG-aware LSR 1745. 
Any other subscribers on subscriber distribution network 1777 that desire this content 
would be boimd to this second CF session. If local delivery network 1725 is implemented 
as a ring architecture, then MPLS traffic may be bound for more than one LSR such as 
LSRs 1735 and 1745. In a network of this type, an MPLS label associated with a 
multicast group may normally be assigned at the creation of any continuous feed session. 

Furthermore, suppose that a second headend or CO (though not shown in FIG. 17) 
were connected to long distance delivery network 1715. The equipment co-located in this 
second headend might be similar to the equipment co-located at the headend shown in 
FIG. 1 7 (i.e., the first headend). This equipment in the first headend possibly includes 
LSR 1705, MPEG source 1707, storage 1709, and DSM-CC SRM 1795. The second 
headend (not shown in FIG. 1 7) would have similar equipment. Also, in this second 
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headend the LSRs would be connected by another local delivery network similar to local 
delivery network 1725 connected to LSR 1705 as shown in FIG. 17. If equipment 
considered part of the assumed second headend attempted to negotiate a continuous feed 
session for the same multimedia stream from MPEG source 1711 that was already 
allocated a continuous feed session by DSM-CC SRM 1 795 in the first headend, then 
MPEG source 1711 could provide the DSM-CC SRM in the second headend (not shown) 
with the same MPLS label already used for the content from MPEG source 1 7 1 1 by the 
first headend. The DSM-CC SRM in the second headend could use the provided MPLS 
label or select a new label. Label conflicts between the two headends can be resolved 
because MPLS labels have only local significance to a particular networic link. Label 
switching routers (LSRs) may change the labels of a packet as it comes into the LSR from 
one link and leaves the LSR through another link. 

MPLS or other label switching protocols with similar features allows the previous 
example to work properly with packets passing through both MPEG-aware and non- 
MPEG-aware equipment. The network should both assign MPLS labels to broadcast-on- 
demand packets as well as distribute the labels to any equipment in the signal path. In the 
preferred embodiments of the present invention DSM-CC SRM 1 795 may assign the 
MPLS label to the stream during the DSM-CC session setup process. The DSM-CC 
SRM 1795 may then use MPEG DSM-CC signaling to distribute the label to MPEG- 
aware, DSM-CC compliant equipment in the signal path. Distribution interfaces 1755 
and 1775 may terminate the label switched paths (LSPs) of the label switching network or 
the LSPs may extend all the way to subscriber devices such as 1765 and 1785. The 
DSM-CC signaling messages could be carried in IP datagrams that are directly addressed 
to specific equipment involved in a continuous feed (CF) session. In addition, the DSM- 
CC SRM 1 795 could be used to initiate standard signaling such as CR-LDP and to 
provide the information for a constrained path. A constrained path is a path for a flow of 
information packets that is constrained to those path segments that meet the quality of 
service requirements of the information flow. 

As another example of implementing personal television fimctions using the 
preferred embodiments of the present invention, suppose that the headend operator has 
identified the content for a broadcast-on-demand continuous feed session to be a 
candidate for stream control by subscribers. Such stream control may include VCR-like 
fimctions of pausing, rewinding, and fast-forward searching. In order to accomplish the 
stream control fiinctions, the content of the program must be cached in a device such as 
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Storage 1709 before a subscriber chooses to rewind the program. Thus, when the 
continuous feed (CF) session is established, traffic designated for potential stream control 
by subscribers would likely be routed to storage 1 709 for caching in addition to being 
routed to subscribers. 

When a subscriber requests a stream control function such as pause or instant 
replay, the client application must initiate a chain of events in a subscriber device such as 
1785 that results in a DSM-CC Client Session Setup Request. DSM-CC SRM 1795 
would receive the request and setup a DSM-CC Exclusive Session (ES) between storage 
1709 and the requesting subscriber device 1785 including any MPEG-aware components 
in the signal path such as distribution interface 1 775. MPLS labels associated with the 
exclusive session (ES) could be distributed in session setup messages to MPEG-aware 
devices such as storage 1709, LSR 1705, and distribution interface 1775. MPLS labels 
associated with this exclusive session (ES) could be distributed to non-MPEG-aware 
devices such as LSR 1745 using the Label Distribution Protocol (LDP) or by other 
means. Stream control commands such as pause or rewind between subscriber device 
1785 and storage 1709 may use the command set of the DSM-CC user-user signaling 
protocol, or they may be implemented with other commands that have been designed into 
the client and server applications. These example applications are only meant to suggest 
some of the various ways that the embodiments of the present invention may be used to 
advantageously allow deployment of networks with improved functionality. Those 
skilled in the art will be aware of other possibilities suggested by the embodiments of the 
present invention. 

Note that the embodiments of the present invention may be implemented using at 
least one dedicated logical circuit, at least one processor and software, or at least one 
combination circuit that includes at least one processor circuit with software and at least 
one specific dedicated circuit. Those, skilled in the art of implementing protocol 
specifications will be familiar with the design tradeoffs of implementing hardware and 
software functions. It is understood that all such permutations of various 
implementations are included herein. 

The software, which comprises an ordered listing of executable instructions for 
implementing logical functions, can be embodied in any computer-readable medium for 
use by or in connection with an instruction execution system, apparatus, or device, such 
as a computer-based system, processor-containing system, or other system that can fetch 
the instructions from the instruction execution system, apparatus, or device and execute 
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the instructions. In the context of this document, a "computer-readable medium" can be 
any means that can contain, store, communicate, propagate, or transport the program for 
use by or in connection with the instruction execution system, apparatus, or device. The 
computer readable medium can be, for example but not limited to, an electronic, 
magnetic, optical, electromagnetic, infirared, or semiconductor system, apparatus, device, 
or propagation medium. More specific examples (a nonexhaustive list) of the computer- 
readable medium would include the following: an electrical connection (electronic) 
having one or more wires, a portable computer diskette (magnetic), a random access 
memory (RANf) (electronic), a read-only memory (ROM) (electronic), an erasable 
programmable read-only memory (EPROM or Flash memory) (electronic), an optical 
fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note 
that the computer-readable medium could even be paper or another suitable medium upon 
which the program is printed, as the program can be electronically captured, via for 
instance optical scanning of the paper or other medium, then compiled, interpreted or 
otherwise processed in a suitable manner if necessary, and then stored in a computer 
memory. 
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CLAIMS 

*■ 

Now, therefore, at least the following is claimed: 

1 . A method of encapsulating MPEG packets within a label switching protocol, the 
method comprising the steps of: 

unplementing a label switching protocol layer, the label switching protocol 
layer allowing a plurality of label switching devices to forward label 
switched frames based upon a label field in the label switched frames; 

implementing an MPEG protocol layer, the MPEG protocol layer capable of 
carrying muhimedia information; and 

encapsulating the MPEG protocol layer inside the label switching protocol 
layer. 

2. The method of claim 1, wherein the MPEG protocol layer is an MPEG transport layer. 

3. The method of claim 1, wherein the MPEG protocol layer is encapsulated directly 
inside the label switching protocol layer. 

4. The method of claim 1 , wherein the label switching protocol layer is a multiple 
protocol label switching layer. 

5. The method of claim 4, wherein the multiple protocol label switching layer is capable 
of being encapsulated by multiple protocols. 

* 

6. The method of claim 4, wherein the multiple protocol label switching layer is capable 
of encapsulating multiple protocols. 

7. The method of claim 6, wherein the multiple protocol label switching layer is used to 
encapsulate both the MPEG protocol layer as well as a second protocol layer using a 
label that has the same value for both encapsulations. 

8. The method of claim 7, wherein the MPEG protocol layer comprises program content 
while the second protocol layer comprises advertising content. 
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9. The method of claim 7, wherein the MPEG protocol layer comprises advertising 
content while the second protocol layer comprises programs content 

10. The method of claim 7, wherein the second protocol layer is an Internet Protocol G?) 
layer. 

1 1 . The method of claim 4, wherein the multiple protocol label switching layer is the 
Multi-Protocol Label Switching (MPLS) protocol that is defined by the Internet 

Engineering Task Force (IETF). 

12. The method of claim 1 , wherein a label is a value that can be assigned to the label 
field of the label switched frames, the label being distributed to the plurality of label 
switching devices using at least one protocol for label distribution. 

1 3 . The method of claim 1 2, wherein the plurality of label switching devices comprises at 
least one MPEG-aware label switching device, the at least one protocol for label 
distribution comprising a protocol for establishing and releasing sessions between 
MPEG equipment, the protocol for establishing and releasing sessions between 
MPEG equipment being used to distribute the label to the at least one MPEG-aware 
label switching device. 

14. The method of claim 1 3, wherein the protocol for establishing and releasing sessions 
between MPEG equipment is a Digital Storage Media-Command and Control (DSM- 
CC) user-network protocol as defined by the Motion Pictures Expert Group (MPEG). 

15. The method of claim 1 3, wherein the plurality of label switching devices further 
comprises at least one non-MPEG-aware label switching device, the label being 
distributed to the at least one non-MPEG-aware label switching devices using a 
different protocol for label distribution than the protocol for establishing sessions 
between MPEG equipment. 
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The method of claim 1, wherein the label switching protocol layer is capable of 
encapsulating a first MPEG transport stream and a second MPEG transport stream in 
the same conmiunications medium by using a first label for the first MPEG transport 
stream and a second label for the second MPEG transport stream, the second label 
being different ftom the first label, the first MPEG transport stream using Packet IDs 
(PIDs) that are unique within the first MPEG transport stream, and the second MPEG 
transport stream using Packet IDs (PIDs) that are unique within the second MPEG 
transport stream. 
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17. A device for communicating MPEG packets in a label switched environment, the 

device comprising: 

logic configured to implement a label switching protocol layer, the label 

switching protocol layer allowing a plurality of label switching devices 
to forward label switched fiames based upon a label field in the label 
switched firames; 

logic configured to implement an MPEG protocol layer, the MPEG protocol 
layer capable of carrying multimedia information; and 

logic configured to encapsulate the MPEG protocol layer inside the label 
switching protocol layer. 

1 8. The device of claim 1 7, wherein the MPEG protocol layer is an MPEG transport 
layer. 

1 9. The device of claim 1 7, wherein the MPEG protocol layer is encapsulated directly 
inside the label switching protocol layer. 

20. The device of claim 1 7, wherein the label switching protocol layer is a multiple 
protocol label switching layer. 

21 . The device of claim 20, wherein the multiple protocol label switching layer is capable 
of being encapsulated by multiple protocols. 

22. The device of claim 20, wherein the multiple protocol label switching layer is capable 
of encapsulating multiple protocols. 

23. The device of claim 22, wherein the multiple protocol label switching layer is used to 
encapsulate both the MPEG protocol layer as well as a second protocol layer using a 
label that has the same value for both encapsulations. 

24. The device of claim 23, wherein the MPEG protocol layer comprises program content 
while the second protocol layer comprises advertising content. 
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25. The device of claim 23, wherein the MPEG protocol layer comprises advertising 
content while the second protocol layer comprises programs content. 

26. The device of claim 23, wherein the second protocol layer is an Internet Protocol (IP) 
layer. 

27. The device of claim 20, wherein the multiple protocol label switching layer is the 
Mtilti-Protocol Label Switching (MPLS) protocol that is defined by the Internet 
Engineering Task Force (IETF). 

28. The device of claim 17, wherein a label is a value that can be assigned to the label 
field of the label switched frames, the label being distributed to the plurality of label 
switching devices using at least one protocol for label distribution. 

29. The device of claim 28, wherein the plurality of label switching devices comprises at 
least one MPEG-aware label switching device, the at least one protocol for label 
distribution comprising a protocol for establishing and releasing sessions between 
MPEG equipment, the protocol for establishing and releasing sessions between 
MPEG equipment being used to distribute the label to the at least one MPEG-aware 
label switching device. 

30. The device of claim 29, wherein the protocol for establishing and releasing sessions 
between MPEG equipment is a Digital Storage Media-Command and Control (DSM- 
CC) user-network protocol as defined by the Motion Pictures Expert Group (MPEG). 

3 1 . The device of claim 29, wherein the plurality of label switching devices further 
comprises at least one non-MPEG-aware label switching device, the label being 
distributed to the at least one non-MPEG-aware label switching devices using a 
different protocol for label distribution than the protocol for establishing sessions 
between MPEG equipment. 
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The device of claim 1 7, wherein the label switching protocol layer is capable of 
encapsulating a first MPEG transport stream and a second MPEG transport stream in 
the same conmiunications medium by using a first label for the first MPEG transport 
stream and a second label for the second MPEG transport stream, the second label 
being dififerent fiom the first label, the first MPEG transport stream using Packet IDs 
(PIDs) that are imique within the first MPEG transport stream, and the second MPEG 
transport stream using Packet IDs (PIDs) that are unique within the second MPEG 
transport stream. 
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33. A method of communicating a packetized stream of digital multimedia infonnation in 
at least one label switched frame that is communicated through a network, the method 
comprising the steps of: 

obtaining a packetized stream of digital multimedia infonnation, the 

packetized stream of digital multimedia information comprising at 
least one packet that represents at least a portion of the packetized 
stream of digital multimedia information; 

placing the at least one packet of the packetized stream of digital multimedia 
information inside at least one label switched frame; and 

transmitting the at least one label switched frame into the network. 

34. The method of claim 33, wherein the obtaining step comprises the step of generating 
the packetized stream of digital multimedia information. 

35. The method of claim 33, wherein the obtaining step comprises the step of receiving 
the packetized stream of digital multimedia information from at least one input 
source. 

36. The method of claim 33, wherein the at least one packet of the packetized stream of 
digital multimedia information conforms to an MPEG transport protocol. 

37. The method of claim 36, wherein the at least one label switched frame conforms to a 
Multi-Protocol Label Switching (MPLS) protocol. 

38. The method of claim 37, wherein the at least one packet of the packetized stream of 
digital muhimedia information is placed directly inside the at least one label switched 
frame so that the MPEG transport protocol is natively carried inside the MPLS 
protocol. 
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39. A method of recovering a packetized stream of digital multimedia information from at 
' least one label switched frame that is communicated through a network, the method 

comprising the steps of: 

receiving at least one label switched frame from the netwoik; 

retrieving at least one packet that represents at least a portion of the packetized 

stream of digital multimedia information from within the at least one 

label switched frame; and 
rebuilding parts of the packetized stream of digital multimedia information 

based upon the least one packet retrieved from within the at least one 

label switched frame. 

40. The method of claim 39, wherein the at least one packet of the packetized stream of 
digital multimedia information conforms to an MPEG transport protocol. 

41 . The method of claim 40, wherein the at least one label switched frame conforms to a 
Multi-Protocol Label Switching (MPLS) protocol. 

42. The method of claim 4 1 , wherein the at least one packet of the packetized stream of 
digital multimedia information is retrieved from directly inside the at least one label 
switched frame so that the MPEG transport protocol is natively carried inside the 
MPLS protocol. 



-47- 



wo 02/052864 



PCiyUSOl/44264 



43. A communication signal, embodied in a computer-readable medium, comprising: 

at least one packet of a packetized stream of digital multimedia information; 
and 

at least one label switched frame that is used to encapsulate the at least one 
packet of the packetized stream of digital multimedia information) the 
at least one label switched frame comprising information for 
forwarding the communication signal along a label switched path 
(LSP) in a network capable of propagating the communication signal. 

44. The communication signal of claim 43, wherein the at least one packet of the 
packetized stream of digital multimedia information conforms to an MPEG transport 
protocol. 

45. The communication signal of claim 44» wherein the at least one label switched frame 
conforms to a Multi-Protocol Label Switching (MPLS) protocol. 

46. The communication signal of claim 45, wherein the at least one packet of the 
packetized stream of digital multimedia information is encapsulated directly inside the 
at least one label switched frame so that the MPEG transport protocol is natively 

r 

carried inside the MPLS protocol. 
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